Taking Advantage of QuickStart

Taking Advantage of QuickStart

QuickStart is an optimization designed to reduce start-up times for applications that link with DSOs. Each time ld builds a DSO, it updates a registry of shared objects. The registry contains the preassigned QuickStart addresses of a group of DSOs that typically cooperate by having nonoverlapping locations. (See "Using Registry Files" for more information about how to use the registry when you're building a DSO.) If you compile your application by linking with registered DSOs, your application takes advantage of QuickStart: all the DSOs are mapped at their QuickStart addresses, and rld won't need to move any of them to an unused address and perform a relocation pass to resolve all references.

Suppose you compile your application using the -quickstart_info flag, and Quickstart fails. It may fail because:

Your application has directly or indirectly linked with two different versions of the same DSO, as shown in Figure 3-1. In this example, yourApp links with libyours.so, libmotif.so, and libc.so.1 on the compile line. When the DSO libyours.so was built, however, it linked with libmalloc.so, which in turn linked with libc.so.1 when it was created. If the two versions of libc.so.1 weren't identical, yourApp won't be able to use QuickStart.

Figure 3-1 : An Application Linked with DSOs

You link with a DSO that can't use QuickStart. This may occur because the DSO wasn't registered and therefore was assigned a location that overlaps with the location assigned to another DSO.
Your application pulls in incompatible shared objects (in a manner similar to the example shown in Figure 3-1).
Your application contains an unresolved reference to a function (where it takes the address of the function).
The DSO links with another DSO that can't use QuickStart.

Even if QuickStart officially succeeds, your application may have name space collisions and therefore may not start up as fast as it should. This is because rld has to bring in more information to resolve the conflicts. In general, you should avoid having conflicts both because of the detrimental effect on start-up time and because conflicts make it difficult to ensure the correctness of an application over time.

In the example shown in Figure 3-1, you may have written your own functions to allocate memory in libmalloc.so for libyours.so to use. If you didn't use unique names for those functions (instead of malloc(), for example) the way this particular compile and link hierarchy is set up, the standard malloc() function defined in libc.so.1 is used instead of the one defined in libmalloc.so.

For example, suppose the diagram in Figure 3-3 corresponds to the following command:

cc -lyours -lmotif -lc

Since shared objects mentioned on the command line always take precedence over those that are not mentioned, the command above uses the standard malloc() defined in libc.so.1.

To get your own version of malloc() defined in libmalloc.so for libyours.so to use, enter:

cc -lyours -motif -malloc -lc

However, in both of the above examples, if lyours contains malloc(), you'll get that malloc(). (In the examples above, you do not need to specify -lc; it was added for clarity).

Note that conflicts are resolved by proceeding through the hierarchy from left to right and then moving to the next level. See "Searching for DSOs at Run Time" for more information about how the run-time linker searches for DSOs.

Thus, it's not a good idea to allow more than one DSO to define the same function. Even if the DSOs are synchronized for their first release, one of them may change the definition of the function in a subsequent release. Of course, you can use conflicts to intentionally override function definitions; however, make sure you control what is overriding what.

If you use the -quickstart_info option, ld tells you if conflicts arise. It also tells you to run elfdump with the -Dc option to find the conflicts. See the elfdump(5) reference page for more information about how to read the output produced by elfdump.